The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Cybercrime has been increasing at a rapid pace. Damages caused by cybercrime reached about $3 trillion in 2017, and the World Economic Forum estimates that cybercrime damages may reach about $6 trillion in 2021. Even though spending on global cybersecurity is expected to balloon to about $100 billion by 2020, the frequency of cyberattacks continues to increase and severity of the attacks is astounding.
Integrity of sensitive data, ranging from medical records to personal financial information, may be easily compromised because existing security mechanisms are often inefficient and unreliable. In fact, most of the existing approaches for securing electronic data are unable to keep up with the rapid development of sophisticated cyberattacks.
Traditional security systems are based on verification, or authentication, of user credentials, and encryption and decryption of transmitted data. The encryption and decryption may be implemented in compliance with encryption protocol such as the Secure Sockets Layer/Transport Layer Security (“SSL/TLS”) Protocol, the Secure Shell (“SSH”) Protocol, and others.
Encryption protocols, however, have many limitations. For example, they operate under the assumption that integrity of data is sufficiently preserved when a server only authenticates credentials of a user to release and encrypt the data. After the authentication, but prior to delivering data to the user or a system, the data is anonymously encrypted on the server side and then anonymously decrypted on a client side. However, this type of authentication only verifies the user's credentials, not the user himself Therefore, this type of authentication cannot detect whether the user's credentials were provided by a legitimate user or by an imposter who stole the credentials from the legitimate user. This type of authentication has no mechanisms for detecting situations when the credentials have been intercepted and used by the imposter.
One solution to the problem includes implementing the SSL/TLS or SSH authentication on both ends of a data communications pipeline, as it has been done in a Pretty Good Privacy (“PGP”) protocol. However, that approach has an inherent problem with the quality of encryption. If the encryption is based on human created passphrases, then the encryption mechanisms may be quite weak. If the encryption is based on X.509, then the encryption mechanisms are limited by an X.509 certificate, which is typically associated with a device. Since a digital X.509 certificate, which includes an identity of a device, uses the widely accepted, international X.509 public key infrastructure (“PKI”) standard to verify whether a public key is valid, the certificate authenticates the device, not the user. Hence, even if a certificate is implemented on both ends of the data communications pipeline, it certificates that a particular device can communicate with a server, but it does not authenticate the actual user. Moreover, if the particular device is lost, stolen or hacked, the security measures based on that certificate collapse entirely.
Generally, current authentication methods are deficient and remain susceptible to unauthorized access and abuse. The SSL was developed by Netscape™ for use in securing the HTTP that is an application protocol for distributed, collaborative, and hypermedia information systems. For example, when a browser accesses a URL which begins with “https”, the browser uses the HTTP over an SSL connection.
The TLS is the name of the Internet Engineering Task Force (“IETF”) protocol standard that grew out of the SSL 3.0, and is documented by RFC 2246. The TLS has goals and features similar to those of the SSH Transport and User Authentication protocols. It provides a single, full-duplex byte stream to clients, with cryptographically assured privacy and integrity, and optional authentication. However, the TLS differs from the SSH in several ways. For example, in the TLS, a server authentication is optional. Thus, the protocol can support fully anonymous operation, in which neither side is authenticated. Such connections are inherently vulnerable to man-in-the-middle attacks.
In the SSH-TRANS, a server authentication is mandatory, and the mandatory authentication protects against man-in-the-middle attacks. It is possible for a client to skip the step of verifying that the public key supplied by the server actually belongs to the entity that the client intended to contact. However, unless the client explicitly skips the authentication, the SSH-TRANS can withstand the man-in-the-middle attacks.
According to another example, X.509 certificates may be used in the TLS. The implementations may be a bit more cumbersome than in the SSH because the X.509 certificates require implementing a PKI, and managing the X.509 certificates is more complicated than managing the SSH keys. For example, the TLS does not provide the same range of user authentication options than the SSH. Furthermore, the TLS does not have certain features that are available in the SSH, such as the SSH Connection Protocol (“SSH-CONN”). The SSH-CONN uses the underlying SSH-TRANS connection to provide a multiple logical data channels to an application, as well as support for a remote program execution, terminal management, tunneled TCP connections, and flow control.